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Abstract 

We  describe  program  structuring  mechanisms  for  integrating  algebraic,  functioned  and  object- 
oriented  programming  in  a  single  framework.  Our  language  is  a  statically  typed  higher-order 
language  with  specifications,  structures,  types,  and  values,  and  with  universal  and  existential 
abstraction  over  structures,  types,  and  values. 

We  show  that  existential  types  over  structures  generedize  both  the  necessarily  homogeneous 
type  classes  of  Haskell  and  the  necessarily  heterogeneous  object  classes  of  object-oriented  pro- 
gramming languages  such  as  C-|— I-  or  Eiffel.  Following  recent  work  on  ML,  we  provide  separate 
linguistic  mechanisms  for  reusing  specifications  and  structures.  Subtyping  is  provided  in  the 
form  of  explicit  type  conversions. 

The  language  mechanisms  are  introduced  by  examples  to  emphasize  their  pragmatic  aspects. 
We  compare  them  with  the  mechanisms  of  XML-I-,  Haskell  and  Eiffel  and  give  a  type-theoretic 
perspective.  These  mechanisms  have  been  developed  within  a  larger,  ongoing  prototyping  lan- 
guage design  project. 

1      Introduction 

We  describe  program  structuring  mechcinisms  for  a  high-level  Icinguage  currently  under  development 
as  pcirt  of  a  software  prototyping  research  effort.  Our  main  ciim  is  to  support  and  integrate  algebraic, 
functional,  and  object-oriented  programming  in  a  coherent  Icmguage  framework. 

The  language  concepts  described  in  this  paper  cire  intended  to  serve  as  a  platform  for  the  design 
of  the  prototyping  Icinguage  Griffin  [D''"90]  currently  under  development  at  New  York  University. 

Our  Unguistic  mechanisms  can  be  seen  as  a  combination  of  Ada  (generic)  packages  [Uni83], 
ML  polymorphism,  signatures  and  structiu-es  [MTH90],  Eiffel  object  classes  [Mey88],  Haskell  type 
classes  [HW90],  and  (partially)  abstract  types  [MP88].  Oiu-  design  is  most  closely  related  to  the 
recently  proposed  extension  of  Standcird  ML  with  subtyping  and  inheritcince  [MMM91]. 
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We  distinguish  between  three  levels  of  "entities"  in  oui  language:  specifications  at  the  highest 
level,  types  cind  structures  in  the  middle,  and  values  at  the  bottom.^  Specifications  consist  of 
interface  and  constraint  specifications.  Specifications  are  inhabited  by  structures,  which  consist  of 
zero,  one,  or  more  types  and  operations  on  those  types.  A  type,  in  turn,  denotes  a  set  of  VcJues. 
Types,  in  some  sense,  pre-exist  values:  Every  value  has  a  type  and  comes  into  existence  if  amd 
when  its  type  is  defined,  typically  as  part  of  a  structure  definition.  This  may  be  at  language 
design  time  (for  built-in  types)  or  at  progrcim  design  time  (for  user-defined  types).  A  specification 
corresponds  to  its  use  in  algebraic  specification  [EM85];  in  object-oriented  terms  it  Ccin  be  roughly 
equated  to  the  (public)  interface  of  a  class  along  with  its  invariants  and  assertions  (see,  e.g.,  Eiffel 
[Mey88]).  In  ailgebraic  terms  a  structure  is  a  valid  model  of  a  specification,  aind  the  types  in  a 
structure  correspond  to  the  carrier  sets  of  such  a  model;  in  object-oriented  terms  the  types  in 
a  structure  represent  the  data  pzirt  of  a  class  implementation,  and  the  operations  stand  for  the 
methods.  Detailed  comparisons  with  other  languages  are  given  in  Section  2. 

We  distinguish  between  the  explicit  language  cind  the  iniplicit  language.  Static  and  dynamic 
semantics  are  specified  only  for  the  explicit  language  (c.f.  [MH88]).  The  progreimmer  may,  however, 
write  in  an  abbreviated  style  relying  on  the  programming  environment  to  fUl  in  missing  information, 
interacting  with  it,  if  necessciry.  Thus  the  task  of  completing  an  implicit  program  can  be  seen 
as  a  purely  combinatorial  task  that  does  not  have  to  be  supported  in  a  uniform  fashion  in  all 
programming  environments  since  it  is  outside  the  Icinguage  definition  proper.  Several  pieces  of 
information  may  be  inferred  by  a  progrzimming  environment: 

•  "classical"  implicit  type  information,  which  models  universal  polymorphism;, 

•  applications  of  conversion  functions,  which  models  subtyping  (c.f.  [BCGS89]); 

•  structure  resolving,  which  models  static  and  d3nQamic  overload  resolution. 

Whereas  the  type-theoretic  ideas  in  our  approach  have  appeared  in  various  forms  before,  their 
combination  and  application  to  object-oriented  programming  appear  to  be  new. 

Instead  of  implicit  subtyping  we  may  define  explicit  conversion  functions  between  types;  for 
example,  we  may  define  a  conversion  from  integers  to  reals  and  vice  versa,  or  a  conversion  from 
cartesian  colored  points  to  cartesian  points.  This  allows  subtyping  even  for  types  defined  as  part 
of  structures  that  do  not  satisfy  the  rule  of  [CCH"''89],  which  has  been  criticized  by  Meyer  as  too 
restrictive  [Mey89]  and  has  been  adopted  in  an  even  more  restrictive  fashion  in  [MMM91]. 

As  pointed  out  before,  a  class  in  the  object-oriented  sense  is  modeled  by  a  specification  for  a 
single  type  emd,  by  extension,  cdl  structures  that  satisfy  it,  either  by  declaration  or  implicitly.  The 
type  of  a  "generic"  object  of  such  a  class  is  represented  by  the  existential  type  3s  :  SPEC.  \  s\  where 
\s\  denotes  the  type  in  structure  s.  An  element  of  this  type  has  two  components,  a  structure  s 
that  satisfies  specification  SPEC  and  a  value  of  type  \s\.  This  is  an  important  difference  from  the 
approach  taken  in  XML-f  [MMM91]:  there  an  object  hcis  also  two  components,  a  type  component 
and  a  value  component.  The  value  component  consists  of  aU  data  and  all  their  methods.  So  for 
two  XML-I-  objects  we  cannot  be  sure  whether  their  methods  or  their  data  representations  cire 
identiccd.  In  particulEir,  binary  methods  that  operate  on  objects  with  identical  representation  type 
are  problematic  in  that  approach. 

Dynamic  binding  can  be  achieved  by  using  the  structiire  component  of  a  generic  object  and 
selecting  from  it  the  corrf^-^Donding  operation  and  applying  it  to  the  Vcdue  pairt  of  an  object.  For 
example,  x.f{w)  in  a  Icinguage  such  as  Eiffel  is  translated  into 


'Actually  theie  is  aa  even  higher  level,  modules,  that  contain  bindings  for  entities  of  all  lower  levels. 


let   <  s  :  SPEC,  v:  \s\  >=  x  in  s.f{v,  w) 


\x  \.f{val{x),w) 

where  x  is  a  generic  object  consisting  of  a  structure  s  cind  a  value  v.  In  the  implicit  Icinguage  we 
could  have  written  f{x,  w)  with  the  idea  that  the  conversion  val  and  the  structure  modifier  |z|  can 
be  inferred.  Inferring  structure  modifiers  of  this  sort  is  generidly  dynamic  overload  resolution;  if 
the  structure  modifier  is  a  (compile  time)  constant  structure  then  it  is  essentizJly  static  overload 
resolution. 

Specifications  and  structures  are  separate,  as  in  XML+.  This  permits  specifications  with  no 
structures  or  more  than  one  structure,  obviating  the  need  for  deferred  classes  and  artificial  subclass- 
es. Also,  specifications  and  structiires  can  be  independently  reused  —  "inherited"  in  object-oriented 
lingo.  This  permits  an  independent  development  of  specification  enhancement  5ind  implementation 
speciaJization  (c.f.,  [Sny87]). 

Functional  abstraction  over  structures  of  a  specification  makes  it  possible  to  treat  members  of 
an  object  class  as  first-class  functions.  This  is  possible  because  class  members  in  our  leinguage  do 
not  have  implicit  arguments  and  because  the  range  of  applicability  cein  be  precisely  described  by  a 
specification.  For  example,  the  method  "translate"  of  object  class  Point  has  type 

translate[s  :  Point]{p  :  |s|,  z,  j/ :  real)  :  \s\ 

The  paper  is  organized  as  follows:  Section  2  gives  an  overview  of  problems  occurring  in  existing 
object-oriented  languages,  the  fnnctionaJ  language  HaskeU,  and  XML+.  Section  3  introduces  the 
key  features  of  our  language,  called  G  in  the  remaining  text.  Section  4  describes  the  type-theoretic 
foundations  of  G  along  the  lines  of  XML  [MH88]  and  XML+  [MMM91].  We  conclude  with  a 
summary  of  the  contributions  made  and  an  outlook  on  further  research.  Appendix  A  contains  a 
collection  of  program  examples  in  G. 

2      Some  Problems  of  Other  Approaches 

2.1      Object-oriented  Languages 

Most  strongly-typed  object-oriented  languages  [Mey88,Str86]  identify  inheritance  with  subtjrping, 
where  the  subtyping  is  based  on  extensible  record  types  particilly  ordered  with  respect  to  a  sub- 
typing  relation.  This  view  appears  too  restrictive  when  it  comes  to  modeling  certain  algebraic 
structures.  Common  properties  of  classes  are  typicadly  factored  out  in  a  common  superclass,  so 
that  heterogeneous  structiires  Ccin  be  constructed.  To  illustrate  this,  let  us  consider  the  following 
example.  We  define  a  class  of  pcirtially  ordered  objects  with  the  following  signature: 

class   PartialOrder  is 

less:    PcirtialOrder  ->  Bool 

Now  we  refine  PartialOrder  to  a  class  Int  with  an  addition  operation,  as  in 

class   Int   superclass  PatrtialOrder  is 
less:    Int   ->  Bool 

However,  the  definition  of  method  less  in  class  Int  violates  the  contravaxiance  rule  for  function 
subtyping.  Hence  it  is  not  possible  to  define  Int  as  a  subtype  of  PartialOrder.  This  example  shows 


how  the  requirement  that  inherited  cl£isses  be  subtypes  of  their  superclasses  gUeirantees  type  Scifety 
but  inhibits  flexibility. 

Trading  off"  in  the  other  direction,  EiiFel  abcindons  the  contravariance  rule  in  its  type  system 
and  gives  up  static  type  safety  for  the  scike  of  greater  flexibility.  Therefore  we  cam  actucdly  create 
a  class  PartialOrder  of  peirtially  ordered  objects  and  several  subclasses  of  PartialOrder,  e.  g.  Int 
and  String.  Indeed,  the  Eiffel  model  allows  us  to  write  the  following  code: 

bool  compcire( PartialOrder  x,   y) 

retiim  x.lessCy); 
n  =  Int(3); 
8  =  StringC'three") ; 
n. compare (s) 

which  would  lead  to  a  runtime  type  error. 

Another  weakness  of  object-oriented  languages  is  the  identification  of  specification  and  imple- 
mentation in  a  single  construct.  (An  exception  is  the  language  Emerald  [BHJL86],  which  separates 
specification  and  implementation,  but  lacks  a  reuse  mechainism.)  While  the  specification  and  the 
implementation  of  a  class  may  be  syntactically  separate  in  order  to  support  modular  coding,  it  is 
not  possible  to  identify  a  single  specification  with  multiple  implementations.  If  we  tried  modeling 
the  specification  as  a  common  superclass  and  the  implementations  as  subcljisses,  we  would  run  into 
two  problems.  The  first  one  is  the  contravciriance  problem  mentioned  above.  The  second  problem 
has  to  do  with  the  interoperability  of  objects  of  the  same  specification,  but  different  implementation. 
As  an  example,  consider  the  problem  of  providing  a  hash  table  and  a  linked  list  implementation  of 
a  set.  The  problem  appecirs  in  coding  binary  operations  such  as  "imion"  so  that  they  work  on  a 
pair  of  hash  tables  or  a  pair  of  linked  Est  representations,  but  not  necessarily  on  mixed  pairs.  In 
an  object-oriented  language  tinion  will  always  have  to  work  on  mixed  pairs  as  well. 

2.2     Haskell  Type  Classes 

Haskell  ([HW90])  provides  an  overloading  mechcinism  ([WB89])  which  is  drfi"erent  from  the  subtyp- 
ing  found  in  traditional  object-oriented  languages  and  solves  the  problem  described  above.  Instead 
of  capturing  common  properties  of  severed  classes  by  deriving  them  from  a  common  superclass,  in 
Haskell  such  classes  are  exphcitly  declared  to  be  instcinces  of  the  same  type  class.  Unlike  a  class  in 
object-oriented  languages,  a  type  class  is  not  a  type  itself.  Instead,  it  specifies  certain  properties 
required  of  its  instance  types. 

In  Haskell,  we  could  express  the  orderedness  of  type  Int  by  defining  PartialOrder  as  a  type 
class,  cind  declaring  Int  and  possibly  other  types  as  instcinces  of  PartialOrder.  We  are  allowed  to 
construct  hiercirchies  of  type  classes.  We  may  define  e.  g.  a  type  class  Hum  with  nimaerical  operations 
as  a  subclass  of  PartialOrder.  Int  could  then  be  made  an  instance  of  Num,  cdong  with  other  types 
such  as  Float. 

Nevertheless,  the  Haskell  model  has  several  major  shortcomings.  First,  Haskell  does  not  provide 
a  mechanism  for  inheritance  at  the  implementation  level.  Each  instance  of  a  type  dciss  has  to  be 
implemented  without  reusing  other  implementations.  Second,  Haskell's  type  classes  Ccinnot  be 
parametrized  nor  used  as  parameters  of  type  constructors.  For  exaimple,  it  is  not  possible  to  define 
a  list  over  the  type  class  Num  whose  members  could  be  of  any  type  declared  as  an  instance  of  Num. 
Neither  is  it  possible  to  define  a  type  class  Set  parametrized  by  the  element  type.  See  [Ode90,OL91] 
for  a  detailed  treatment. 


2.3     XML+ 

Various  disadvantages  of  existing  object-oriented  languages  have  been  recognized  and  described 
in  [Mit90b,MMM91].  XML-I-  is  &d.  extension  of  the  Stcindaird  ML  module  system  and  improves 
over  both  the  object-oriented  and  the  Haskell  style  in  a  number  of  respects.  A  major  shortcoming 
of  object-oriented  languages  is  the  merging  of  specification  and  implementation  of  classes.  One 
consequence  of  this  merging  is  the  difficulty  of  providing  multiple  implementations  of  the  same  class 
specification.  Another  problem  stems  from  the  observation  that  specification  ajid  implementation 
inheritance  (extension)  often  work  most  naturailly  in  opposite  ways.  Consider  e.  g.  queues  and 
stacks  as  seen  in  section  A.  It  is  nattiral  to  specify  a  queue  as  an  extension  of  the  specification  of 
a  stack,  since  a  queue  provides  at  least  cill  the  operations  that  cire  part  of  a  stack.  On  the  other 
hand,  a  stack  implementation  can  easily  be  obtained  from  a  queue  implementation  by  hiding  the 
operations  that  are  not  needed.  However,  we  lose  this  abstraction  if  we  implement  a  queue  in  terms 
of  a  stack,  because  the  queue  implementation  would  have  to  know  the  representation  of  the  stack 
to  provide  the  additionaJ  operations  [Sny87]. 

XML-I-  sepeirates  specification  and  implementation,  using  an  extension  of  ML  signatures  for 
specifications,  and  an  extension  of  ML  stnictiires  for  implementations,  combined  with  separate  in- 
heritcince  mechanisms.  Sepeirate  mechcinisnis  for  specification  eind  structure  subtyping  are  provided. 
F-bounded  polymorphism  ([CHC90])  is  used  to  allow  polymorphism  over  families  of  structurally 
similar  types  of  objects  that  do  not  necesscirily  have  a  subtyping  relationship.  Furthermore,  XML-I- 
structures  support  traditionad  abstract  data  types,  i.  e.  pairs  consisting  of  a  representation  type 
and  a  set  of  operations  on  that  type,  which  are  not  present  in  existing  object-oriented  languages. 
XML-I-  introduces  internal  interfaces  which  £ire  used  by  multiple  implementations  to  interact  with 
one  another. 

We  have  found  some  short-comings  in  the  XML+  support  for  object-oriented  programming, 
which  we  will  illustrate  below.  First,  we  find  it  importeint  to  be  able  to  specify  that  two  distinct 
objects  have  identiccd  representation  type  and  methods.  In  existing  object-oriented  languages  such 
as  C-f -f  it  is  normally  the  case  that  two  instances  of  the  same  class  differ  semanticedly  only  in  their 
state.  XML-I-,  however,  lacks  a  mechanism  to  guarantee  this,  as  illustrated  by  an  excimple: 

specification  OBJ  =  spec 

val  get:   unit  ->   int ; 
val  put :    int  ->  unit 
end 
structure  Objl:   OBJ   =   struct 

val  i:   ref  int   =  ref  0; 
fun  get   0   =    !i; 
fun  put  k  =  i    :=  k 
end 
structure  0bj2:   OBJ  =   struct 

val  i:    ref   int   =  ref  2; 
fun  get    0    =   2   *    !i; 
fun  put  k   =   i    :=  k   +  3 
end 

Given  specification  OBJ,  we  Ccin  declare  objects  that  are  instances  of  OBJ  and  therefore  satisfy  the 
signature  requirements.  However,  we  axe  free  to  implement  the  components  of  the  insteinces  in 
diff"erent  ways  as  long  as  the  signature  is  correct.  There  is  no  direct  mechanism  to  construct  several 
instances  of  the  same  implementation;  it  Ccin  be  approximated  using  code  reuse  at  structure  level. 
G  provides  specifications,  structures,  and  objects.  While  specifications  contciin  signature  infor- 
mation, structures  implement  representation  and  operations  of  a  class  or  an  ADT.    By  creating 


several  instances  of  the  same  structure,  we  are  siire  that  they  axe  identical  and  only  differ  in  their 
state. 

The  second  problem  stems  from  the  inheritance  mechanism  for  structures  and  appears  in  a 
nimaber  of  object-oriented  Izmguages.  Inheritance  in  XML-I-  Ccin  be  described  as  a  textual  copying 
combined  with  a  renaming  amd  visibility  control  mechanism.  Consider  the  following  excimple: 

structure  Amount  =   struct 

type  t   =  int   *  int; 
val  v:    t   =    (12,   95) 
end 
structure  UseAmoimt  =  struct 

copy  Amount ; 
fun  dollars   ()   =  #1  v; 
fun  pennies   ()   =  #2  v 
end 

This  textual  copy  mechanism  is  not  safe;  it  may  lead  to  problems  known  from  other  Icinguages  such 
as  Smalltalk  [GR83].  The  problem  generally  appears  in  the  part  of  the  code  that  is  copying  from 
the  other  structure.  If  Amount  is  redefined  with  the  representation  given  below,  a  type  error  occurs 
in  DseAmount. 

structure  Amount  =  struct 

type  t  =  int; 
val  V  =  1295 
end 

At  specification  level,  besides  textujil  copying,  XML-I-  provides  extension  and  restriction  of 
specifications,  which  result  in  subtypes  and  supertypes  of  the  originzd  specification,  respectively. 
Unfortimately,  it  is  not  clear  how  a  recursive  specification  is  extended.  By  a  recursive  specification 
we  meain  one  whose  ncime  appears  in  the  signature  of  one  of  its  components.  Suppose  we  extend 
the  specification 

specification  StackClassCtype  t]    =  spec 

fun  push:   t  ->  StackClassCt] 

to  another  specification 

specification  QueueClassCtjrpe  t]    =  extend  StackClassCt]   with 

fun  enqueue:   t   ->  QueueClass [t] 

Does  the  component  push  of  QueueClass  have  type  t  ->  StackClassCt]  or  t  ->  QueueClass Ct] ? 
Clearly,  the  latter  would  be  more  desirable  as  we  might  Wcint  to  push  an  element  onto  our  queue 
first,  and  then  enqueue  another  one;  hence  we  want  push  to  return  a  queue.  Traditional  object- 
oriented  languages  provide  constructs  such  as  my  type  or  like  current,  while  G  solves  this  problem 
by  identifying  the  object  type  with  the  representation  type,  and  not  with  the  type  of  the  whole 
structure. 

Although  XML+  contributes  to  the  solution  of  various  problems  present  in  the  object-oriented 
paradigm,  it  does  not  completely  resolve  certain  issues  regarding  code  reuse  and  class  specification. 

3      Specifications,  Types,  and  Values 

In  this  section,  we  will  present  the  data  abstraction  mechanisms  of  our  language  G.  Let  us  give  an 
overview  of  the  concepts  and  terms  we  use,  before  we  address  the  technical  issues. 


3.1      Basic  Concepts  and  Terminology 

type:  A  type  denotes  a  collection  of  (first-class)  vcdues.^  A  type  is  not  useful  by  itself;  it  is  normally 
defined  as  a  component  of  a  structure,  which  provides  operations  involving  that  type.  Types 
are  either  primitive,  such  as  int,  bool,  string,  or  constructed  from  primitive  types,  such  as 
function  types,  ML-style  datatypes,  etc.  In  G,  monomorphic  cind  polymorphic  functions  axe 
considered  first-class. 

value:  A  value  is  an  inhabitcint  of  a  type.  Values  are  exactly  the  first-claiss  entities  in  G,  i.  e.  they 
CEin  be  returned  as  the  result  of  a  conditional  expression,  passed  as  a  function  parameter,  or 
stored  in  a  variable.  Examples  are  3 ,   false,  fn[t   ::     Type]    (x   :     t)  =>  x. 

structure:  Structxires  in  G  are  vievred  the  same  way  as  in  ML.  A  structure  is  an  encapsulation  unit 
that  consists  of  zero,  one,  or  more  types,  and  zero,  one,  or  more  values.  Structures  inhabit 
specifications;  although  we  could  say  that  specifications  are  types  of  structures,  we  prefer  to 
use  the  term  "type"  exclusively  for  types  of  first-class  VcJues.  Structures  containing  one  or 
more  types  are  not  first-class  entities,  since  that  would  inhibit  static  typing.  They  are  at  the 
same  level  as  types;  in  fact,  a  type  may  be  identified  with  a  structure  containing  only  that 
(representation)  type,  but  no  operations.  All  predefined  types  are  actually  representation 
types  of  structures  that  define  the  operations  on  them. 

functor:  A  functor  is  a  structure  template  pareimetrized  by  (compile-time)  values,  types,  or  struc- 
tures. Functors  are  inhabitants  of  paramaetrized  specifications. 

specification:  A  specification  defines  the  interface  of  a  structure,  i.  e.  its  visible  components.^  A 
structure  is  said  to  inhabit,  or  implement  a  specification  if  it  provides  definitions  for  all  the 
entities  required  by  the  specification.  Specifications  Cein  be  parametrized  by  VEilues,  types, 
or  structures;  in  that  case,  they  are  specifications  of  functors.  So  far,  our  specifications 
correspond  to  ML  signatures  or  Ada  package  specifications.  Furthermore,  specifications  can 
be  parametrized  with  respect  to  other  signatures. 

module:  A  module  is  a  compilation  or  librziry  imit  that  contains  bindings  for  entities  of  all  lower 

levels,  i.  e.  specifications,  structures,  types,  and  values. 

hidden  type  and  generic  object:  In  mamy  situations,  we  want  to  have  objects  that  are  instances 
of  some  implementation  of  a  specification,  but  we  do  not  Ccire  which  one.  Such  generic 
objects  consist  of  a  (hidden)  structure  component  eind  the  object  value,  whose  type  is  the 
representation  tjrpe  of  the  structure  component.'*  They  provide  dynamic  dispatching  on 
subclasses  in  the  sense  that  the  structure  component  is  hidden  and  may  be  locally  opened  in 
order  to  access  the  methods  implemented  on  that  particular  representation  type.  The  Vcdue 
component  can  be  accessed  only  within  an  open  statement;  this  restriction  allows  us  to  treat 
hidden  types  as  first-class  types. 

reuse:  Code  reuse,  or  inheritance,  can  occur  both  at  structure  level  and  specification  level.  Reuse 
at  structure  level  is  not  yet  well-understood  (see  the  discussion  in  [Mit90b]),  eind  is  cxirrently 
handled  by  textual  copying,  although  we  are  not  satisfied  with  this  method.  At  specification 


'Hence  in  type-theoretic  terms,  types  in  G  are  "small"  tjrpes.  See  Section  4  for  a  brief  discussion  of  polymorphic 
functions. 

'Optionally  a  specification  can  also  contain  constraints,  which  are,  however,  of  no  further  relevance  here. 
*Such  hidden  types  are  called  existential  types  in  type-theoretic  terminology,  see  [MP88] 


level,  new  specifications  cjin  be  derived  from  previous  ones  by  copying,  adding,  or  omitting 
parts  of  the  specification. 

subtyping  and  conformity:  At  type  level,  G  provides  no  implicit  subtyping;  instead,  explicit 
conversion  functions  may  be  used.  This  gives  us  higher  flexibility  for  forms  of  subtyping  that 
do  not  satisfy  the  restrictive  contravariance  rule  for  record  subtyping  [CHC90].  On  the  other 
hand,  we  have  implicit  conformity  between  specifications;  for  example,  when  a  parameter  is 
specified  by  a  required  interface,  any  structure  that  satisfies  that  interface  may  be  passed. 

3.2      Specification  and  Implementation 

Let  us  now  demonstrate  how  types  c£in  be  specified  Jind  implemented.  A  specification  states  the 
abstract  properties  of  a  typ^i  i.  e.  how  a  type  will  be  used,  but  does  not  specify  any  concrete 
implementation  details  (except  possibly  for  representation-independent  bodies  of  operations,  as  we 
will  see  shortly).  Consider  the  following  example  of  a  pcirametrized  stack: 

spec  Stack [elem  ::   Type]    =  stack   ::   Type  with 
new:   stack 

push:   stack  *  elem  ->  stack 
pop:   stack  ->  stack 
top:    stack  ->  elem 
isempty:   stack  ->  bool 
—  constraints 

Note  that  Type  itself  is  a  specification.  Indeed,  it  is  the  most  general  specification  in  the  sense  that 
it  does  not  specify  any  operations  on  its  instance  types. 

Structures  are  instances  of  specifications  and  describe  how  abstract  objects  are  implemented. 
The  following  structures  give  two  alternative  implementations  of  the  specification  Stack: 

struct  liststackCe   ::   Type]    ::   Stack  [e]   =  List[e]   with 
new  =  nil 

pushd,   e)    =  e    :  :    1 
pop  =  tl 
top  =  hd 
isempty(l)   =   (1  =  nil) 

struct  arraystackCe]    =   •[  a:    Array [0. .MAXSIZE]   of  e,    i:    O..MAXSIZE  >  with 
new  =  {  a  =  new[Array[0. .MAXSIZE]] ,   i  =  0  } 
pu8h(s,   e)    =  8{a   :=   B.a[i+1    :=  e]  ,   i    :=   s.i  +   1} 
pop(s,   e)    =   B-(i    :=   s.i  -   1} 
topCs)   =  s.aEs.i] 
isemptyCs)   =    (s.i  =   0) 

They  are  functional  implementations  in  the  sense  that  they  do  not  carry  a  state.  A  more  "object- 
oriented,"  imperative  implementation  could  be  given  by 

struct  refliststack[e]    ::    Stack  [e]    =   ref  ListEe]   with 
new  =  ref  nil 

push(s,   e)    =    (b    :=  X    ::    is;    s) 
popCs)   =    (s    :=   tl(!s);    s) 
top(s)    =  hd(!E) 
isemptyCs)   =    (Is   =  nil) 


Let  us  now  demonstrate  how  specifications  can  be  reused  (inherited).  From  an  abstract  point 
of  view,  a  queue  is  a  stack  with  some  more  operations.  When  specifying  a  queue,  it  is  natural  to 
use  the  specification  of  Stack  and  tack  on  the  additional  operations. 

spec  Queue [elem : :   Type]    =  Stack [elem]    with  stack  as   queue  and 
append:    elem  *   queue  ->  queue 
delete:   queue  ->  queue 
last :    queue  ->  elem 
isfull:   queue  ->  bool 

Note  how  the  virtual  representation  stack  is  renaimed  to  queue  and  used  in  the  signature  of  the 
additional  operations.  The  representation  corresponds  to  "mytype"  in  typical  object-oriented  Icin- 
guages. 

Having  just  seen  reuse  of  specifications,  let  us  introduce  reuse  of  implementations,  for  which 
G  provides  a  separate,  quite  flexible  mechanism.  Aiming  at  implementing  queues,  we  start  by 
extending  the  list  implementation  of  a  stack,  and  then  giving  an  eirray-based  implementation  of  a 
queue  not  inherited  from  any  other  structure. 

struct  li8tqueue[elem]    ::   Queue [elem]   =  liststack[elem]   with 
(liststackCelem] ) :   listqueue [elem]   ->  Il8t8tack[elem] 

—  automatically  inferred  type  conversion 
append(e,    (c    ::    q))    =  c    ::   append(e,  q) 
append(e,  nil)   =   [nil] 
delete(c   ::  nil)   =  nil 
delete(c   ::   1)    =  c    ::   delete(l) 
la8t(c   : :  nil)   =  c 
la8t(c   ::  1)  =  last(l) 
i8full(l)  =  false 

struct  EO'rayqueue [elem]    ::   Queue [elem]   =  {  a:   Array [0. .NiXSIZE]   of  elem, 

i,    j:   O..MAXSIZE,  full:  bool>  with 
new  =   {  a  =  new[Array [0. .MAXSIZE]  ,   i  =  MAXHUM,   j    =  0,   full  =  false  } 
push(q,   e)    =  if   isfullCq)   then  raise  full  else 

q-[a   :=  q.a[j    :=  e]  ,   j    :=  next(q.j),  full  = 
(prev(q.j)   =  q.i)} 
pop(q)   =  if   isempty(q)   then  raise  empty  else 

q{j    :=  prev(q.j)} 
top(q)   =  if   isemptyCq)   then  raise  empty  else 

q.a[prev(q.j)] 
append(e,  q)   =  if  isfull(q)  then  raise  full  else 

q-[a   :=  q.a[i    :=  e]  ,   i    :=  prev(q.i),   full  = 
(prev(q.j)   =  q.i)> 
delete(q)   =  if   isempty(q)   then  raise  empty  else 

q-[i    :=  next(q.i)> 
last(q)   =   if   isempty(q)   then  raise  empty  else 

q.a[next (q. i)] 
isempty(q)   =  not   isfulKq)   cind   (prev(q.j)   =  q.i) 
isfulKq)   =  q.full 
—  auxiliary  definitions 

next(i:    int)   =   if   i   =  MAXSIZE  then  0  else  i+1 
prev(i:    int)   =   if   i   =  0  then  MAX 

Having  written  such  an  implementation  of  a  queue,  one  might  be  curious  whether  it  can  be  made 
into  a  stack  implementation  simply  by  getting  rid  of  part  of  the  operations  provided.    By  giving 


arrayqueue  the  signature  Stack,  we  hide  the  operations  in  arrayqueue  that  are  not  peirt  of  Stack.  As 
elaborated  in  section  2,  existing  object-oriented  languages  do  not  typically  provide  this  flexibility: 

struct  array 8tack2[elem]    ::    Stack [elem]   =  aLrrayqueue [elem] 

3.3     Hidden  Types  and  Dynamic  Dispatching 

Suppose  we  axe  given  a  specification  Point  along  with  some  implementations  (which  we  are  not 
showing). 

spec  Point  =  t    : :   Type  with 

new:   real  ♦  real  ->  t 

x:   t  ->  zeal 

y:   t  ->  real 

r:   t  ->  real  =  8qrt(x(p)"2  +  y(p)"2) 

theta:   t  ->  real  =  arctan(y(p)/x(p)) 

eq(p:   t,   q:   t):   bool  =  x(p)   =  x(q)   and  y(p)   =  y(q) 

treaislate(p:   t,   u:   real,   v:   real):   t  = 

neH(x(p)+u,  y(p)+v) 
scale (p:   t,   s:   real):  t  = 

neH(x(p)*8,  y(p)*8) 
sqdistanceCp:  t,  q:    t):   real  = 

(x(p)   -  x(q))-2  +   (y(p)  -  y(q))-2 

A  generic  point  would  then  have  the  type 

type  AnyPoint  =  some  P    ::   Point  with   |P| 

Another  example  of  dynamic  dispatching,  which  also  involves  multiple  inheritemce,  is  given  in 
Appendix  A. 

4      Type-theoretic  Aspects 

The  G  type  system  is  based  on  an  explicitly  tjrped,  predicative  lambda  calculus  and  can  be  consid- 
ered as  an  extension  of  the  type  systems  described  in  [Mac86,MH88,MMM91].  In  this  section,  we 
will  briefly  review  the  concepts  underlying  those  type  systems  and  then  outline  the  G  type  system. 

XML  is  a  language  introduced  in  [MH88]  in  order  to  explain  more  precisely  the  type  system 
of  Standard  ML,  including  its  module  facility.  The  type  system  of  XML  provides  two  imiverses 
of  types,  Ui  and  U2,  which  are  informedly  called  "small"  and  "large"  types,  respectively.  This 
sepairation  reflects  the  phase  distinction  between  the  static  evaluation  of  modules  and  the  dynamic 
evciluation  of  values  in  Standard  ML.  The  imiverse  of  all  values,  Uo,  contains  aH.  entities  whose 
types  are  members  of  Ui.  XML  may  be  defined  relative  to  an  arbitrary  collection  of  base  types, 
e.  g.  integers  and  booleans,  cind  user-defined  algebraic  free  types.  Its  small  types  include  any  type 
expression  constructed  using  only  base  types,  monomorphic  type  variables,  and  the  function  space 
constructor  — ►. 

The  large  type  universe  of  XML  corresponds  to  Standard  ML's  polymorphic  types  and  module 
facility.  U2  contaiins  Ui  itseif,  polymorphic  functions,  and  types  constructed  from  other  members  of 
U2  using  generad  sum  cind  product  operations.  We  will  now  review  these  operations  as  introduced 
in  [Mac86]. 

Let  A  he  a  set,  and  B  a  family  of  sets  indexed  by  A,  meaning  that  5(a)  is  again  a  set  for  each 
a  e  A.  Then  the  general  product  of  A  and  B,  written  IIi  :  A.B{x)  is  the  set  of  functions  /  from  A 
to  the  tmion  Ux^aB{x)  such  that  for  each  a  e  A,  we  have  f(a)  £  B{a),  i.  e. 
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na;  :  A.B{x)  =  {f  e  A  ^  U^g^J?(2)  |  Va  G  A.f{a)  e  B{a)} 

Note  that  in  the  degenerate  case  in  which  B  is  constant,  the  general  product  reduces  to  the  function 
space  A  -*  B. 

The  general  sum,  written  Ei  :  A.B{x),  for  a  set  A  £ind  a  fanuly  of  sets  B  indexed  by  A,  is  the 
set  of  pairs  <  o,  6  >  such  that  a  E  A  and  b  6  B{a),  i.  e. 

Si  :  A.B{x)  =  {<  a,b>e  Ax  U^eAB{x)  \  b  e  B{a)} 

In  the  degenerate  case,  the  general  sum  reduces  to  the  cartesian  product  A  x  B.  We  may  apply 
projection  functions  |.|  (witness)  and  val  to  members  of  general  sxma  types  which  return  the  first 
and  second  component  of  the  member,  respectively. 

Viewing  types  as  sets,  XML  incorporates  general  sum  and  product  types  into  ZTj  by  reqiiiring 
that  the  index  type  A  and  the  types  contained  in  the  family  B  be  members  of  f/2-  The  following 
are  examples  of  general  sima  and  product  types  and  members  of  such  types: 

<  int,Z  >:         St  :  Ui.t 

nil  :     lit  :  Ui.list{t) 


As  seen  in  [Mac86,MH88],  the  signatures  of  Standard  ML  may  be  viewed  as  syntactic  sugar  for 
general  sum  types,  and  ML  structures  and  functors  as  a  notation  for  members  of  general  sum  aind 
product  types,  respectively.  Although  functor  signatures  are  not  provided  in  ML,  they  could  be 
described  by  generad  product  tjqjes. 

The  language  XML+  is  presented  in  [MMM91]  eind  can  be  seen  as  a  generalization  of  XML  incor- 
porating several  new  features.  It  generalizes  signatures  by  providing  not  only  structure  signatures 
in  form  of  general  simas,  but  also  functor  signatures  in  form  of  general  product  types.  In  addition, 
XML+  features  pajcimetrized  signatures,  which  have  types  of  the  form  U2  —*  U2  —*  ■  ■  •  —*  U2, 
technically  leaving  the  boundaries  of  C/2.  Another  feature  included  in  XML-I-  is  an  impredicative 
treatment  of  existential  types  and  a  related  implicit  coercion  from  U2  to  Ui.  We  will  give  a  brief 
overview  of  existential  types  emd  their  use  in  XML+. 

Existential  types  axe  introduced  in  [MP88,CW85]  and  model  the  progrcimming  language  concept 
of  type  abstraction.  Using  the  notation  of  [Mac86],  an  existenticd  type  is  expressed  as  3t  :  Ui.B{t), 
where  B  is  a  type  expression  possibly  containing  free  occurrences  of  t.  Values  of  such  types  cire 
created  by  expressions  of  the  form  hide^f. u^  gf^t^r M ,  where  t  is  a  J/j  type  and  M  is  an  expres- 
sion of  type  B{t).  The  only  expression  avciilable  on  members  of  existential  types  has  the  form 
open  M  as  x[t]  in  N.  It  has  type  p,  asstmaing  M  :  3t  :  Ui.B{t)  and  x  :  B{t)  ^  N  :  p,  with  the 
restriction  that  t  does  not  leave  the  scope  of  N ,  i.  e.  appear  free  yd.  p  or  the  type  of  any  vciriable 
appearing  free  in  N .  Locally  within  A^,  t  refers  to  the  type  component,  and  x  to  the  value  com- 
ponent. Although  existential  types,  similarly  to  generad  sum  types,  have  a  type  component  which 
is  a  member  of  f/i,  they  Ccin  be  considered  as  members  of  Ui.  This  is  possible  because  the  type 
component  is  hidden  and  may  be  accessed  only  locally  as  an  opaque  type  newly  generated  with 
each  open  operation. 

XML+  provides  signatures  as  general  sum  types;  however,  the  structures  described  by  those 
signatures  may  be  treated  as  members  of  existentiaJ  types  so  that  they  have  small  types.  This 
flexibility  is  achieved  by  recognizing  that  there  is  a  canoniccd  coercion  function 

/iide:St  :  Ui.B{t)  ^  It  :  Ui.B[t) 
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which  simply  hides  the  identity  of  the  type  component  of  a  structure  and  is  reflected  in  the  typing 
niles. 

G  differs  from  XML  in  severed  ways.  While  maintaining  a  hierarchy  of  two  type  universes, 
it  combines  general  sima  types  in  U2  with  a  modified  notion  of  impredicative  polymorphism  emd 
bounded  existential  types.  Within  the  universe  Ui,  G  identifies  structures  with  the  underlying 
representation  types.  We  will  now  elaborate  on  these  chciracteristics. 

Polymorphism  in  G  appears  at  two  levels.  Since  it  is  desirable  to  treat  polymorphic  functions 
as  first-class  values,  we  consider  polymorphic  types  such  as  IK  :  U\.B{t),  or  commonly  written 
V<  :  U\.B{t),  as  types  in  Ui.  We  can  now  write  first-class  functions  parametrized  by  polymorphic 
functions,  e.  g. 

g  =  A/  :  (V<  :  Ui.t  ^  t).{f  int  3,/  bool  false) 

This  option  is  described  in  [MH88],  and  the  question  whether  the  extension  of  XML  with  this  sort 
of  impredicative  poljmiorphism  is  strongly  normalizing  still  appecirs  to  be  open.  However,  it  is 
believed  to  be  strongly  normalizing  [Mit90a],  since  the  code  of  polymorphic  functions  is  completely 
oblivious  to  the  type  pareimeter.  Analogously,  we  view  functors  of  the  form  Vs  :  U2-B{s),  where 
B{s) :  U2,  &s  members  of  U2,  thereby  allowing  us  to  parametrize  functors  by  other  functors. 

In  addition  to  existential  types  such  as  3t  :  Ui.B{t),  G  provides  signature-bounded  existential 
types  of  the  form  3i  :  C.B{\t\)  as  Ui  types,  where  C  :  E<  :  Ui.F{t)  and  lf|  denotes  the  first 
(witness)  component  of  t  (see  [CW85,Mac86]).  Such  types  are  used  to  model  peirtial  abstraction, 
meaning  that  the  only  known  property  of  the  hidden  structure  is  its  membership  in  a  signature  C. 
They  are  useful  when  modeling  object-oriented  programming,  where  we  have  objects  with  a  known 
interface  but  a  hidden  representation.  As  an  excunple,  consider 

C    =     Et  :  Ui.t  ->  bool 
S    =     <  int,Xx  :  int.x  <0>:  C 
s     =     hidesfc.\t\S  3 
Now  we  can  use  the  squeire  operation  when  we  locally  open  s  as  in 
open  s  as  x[t]  in  {val{t)){x)  :  bool 

In  contrast  to  XML-f,  which  models  classes  as  general  sum  types  and  objects  as  their  members, 
G  has  a  3-level  hierarchy  viewing  objects  as  values,  object  types  (classes)  as  Ui  types,  and  signatures 
(class  interfaces)  as  U2  types.  At  the  level  of  Ui,  we  identify  structures  that  group  a  small  type 
with  operations  on  that  type  with  the  witness  type  itself,  which  we  view  as  a  mere  set  of  values.  As 
seen  in  the  previous  example,  C  is  a  class  interface  specifying  a  square  operation,  5  is  a  structure 
with  interface  C,  cind  3  is  an  object  of  class  5,  i.  e.  a  value  of  type  \S\. 

G  has  a  notion  of  signature  conformity  similar  to  XML's. 

5      Conclusion 

We  have  developed  a  language  framework  that  integrates  cJgebraic,  functional,  and  object-oriented 
programming  in  a  vinifonn  way.  We  have  shown  that  abstraction  over  structiu-es  plays  a  critical 
role  in  offering  flexible  mcinipulation  of  both  homogeneous  cind  heterogeneous  data.  This  combines 
the  advantages  of  algebrciic  cind  object-oriented  progranuning. 

Severed  important  open  problems  remadn.  Type  reuse  and  type  derivation  need  to  be  worked 
out  carefully  to  overcome  the  non-robust  nature  of  literally  copying  structures.  Furthermore,  the 
generalized  type  inference  problem  of  completing  prograims  in  o\ir  imphcit  language  need  to  be 
addressed  where  types,  structure  modifiers  cind  conversion  functions  may  be  elided. 
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A     A  Collection  of  Examples  in  G 

This  section  contadns  a  number  of  examples  that  we  considered  during  the  design  of  our  language. 

A.l      Points,  Circles,  and  Rectangles:  Hidden  Types  and  Dynamic  Dispatching 

We  will  start  with  another  example  of  dyneimic  dispatching,  which  also  involves  mviltiple  inheritance. 
It  is  based  on  the  example  in  Section  3.  Given  the  specification  for  Point  from  Section  3,  we  add 
two  specifications,  one  for  graphiccil  objects  and  one  for  colored  objects. 

type  Color  =   {  red,   green,   blue  } 

spec   ColorObj   =   colorobj    : :    Type  with 
color:    colorobj   ->   Color 

spec   GraphObj   =  graphobj    : :    Type  with 
drao:    graphobj   ->  void 
scale :    graphobj   *  real  ->   graphobj 

Using  mxiltiple  inheritance,  we  obtain  a  new  specification  for  graphiccil  objects  that  also  have  a 
color: 

14 


spec  ColGraphObj   =   ColorObj  with  colorobj   as  colgraphobj  and 
GraphObj  with  graphobj   as   colgraphobj 

Let  us  define  some  geometric  objects  we  can  draw.  Note  how  they  use  the  type  AnyPoint  we  defmed 
above,  since  we  do  not  care  how  the  points  constituting  the  rectangle  are  represented. 

spec  CircleObj   =  GraphObj   with  graphobj   as   circle  emd 
new:   AnyPoint  *  real  ->  circle 
center:   circle  ->  AnyPoint 
radius:   circle  ->  real 
scale:   circle  *  real  ->  circle 

spec  RectjmgleObj   =  GraphObj   with  graphobj   as  rectemgle  and 
new:    AnyPoint  *   AnyPoint  ->  recteingle 
lowerleft:   rectangle  ->  AnyPoint 
upperright:  rectangle  ->  AnyPoint 

Here  are  implementations  for  Circle  and  Rectzmgle. 

struct  gencircle   ::   CircleObj   =  •{  center:   AnyPoint,  radius:   real  }  with 
nesCp,   r)   =  ■[  center  =  p,   radius  =  r  } 
center (c)   =  c. center 
radius (c)   =  c. radius 

scaleCc,   s)   =  ci  radius  =  c. radius  ♦  s  J 
drav(c)   =  let  <s ,   v>  =  c. center  in 

dravcircle(s .x(v) ,   8.y(v),  p. radius) 

struct  genrectsuigle   : :   RectangleObj  = 

{  lowerlef t :   AnyPoint,  upperright:   AnyPoint  }  with 
nes(p,  p')   =  {  loHerleft  =  p,   upperright  =  p'   } 
lowerleft(r)  =  r.lowerleft 
upperright (r)   =  r. upperright 
scale(r,   s)   =  let  <t ,   v>  =  r. upperright  in 

r{  r. upperright  =  t.scale(v,   s)   } 
draw(r)   =  let  <tl,   vl>  =  r.loserleft  and 
<tr,   vr>  =  r. upperright  in 
drawrectangle(tl.x(vl) ,  tl.y(vl),  tr.x(vr),  tr.y(vr)) 

Finally  we  come  to  the  interesting  part.  We  define  a  type  for  any  graphical  object  and  a  function 
which  locally  dispatches  such  an  object  to  its  proper  drawing  function.  Remember  that  such 
objects  are  actually  pairs  of  a  hidden  type  component,  which  gets  bound  to  s,  and  a  value  of  the 
representation  type  contained  in  the  hidden  type  component,  here  bound  to  v. 

type  AnyGraphObj   =   some  G:    GraphObj   with    IGI 

draw(g:    AnyGraphObj)   =   let   <e,   v>   =  g  in  s.drasCv) 

Now  we  can  define  a  heterogeneous  hst  type  of  graphiccil  objects  and  draw  such  a  hst. 

struct  GraphList  =   List [AnyGraphObj]   with 
draw:    List [AnyGraphObj]    ->  void 
draw(nil)   =    (); 
draw(<s,v>: :1)   =  s.draw(v);   draw(l) 
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Hidden  types  actually  offer  more  than  what  we  just  showed.  The  following  example  shows  how 
they  can  be  used  to  group  two  points  of  the  same  type,  where  we  only  cjire  that  the  type  is  the 
same,  but  not  which  particvdar  implementation  of  the  specification  Point. 

type  APPair  =  some  P    ::   Point  with    IP  I    •    IP  I 

eq(pp:   APPair):   bool  =    Ipp I .eq(pp. 1 ,  pp.2) 

Using  such  a  pair  type,  we  can  define  a  safe  equality  function  that  takes  a  pair  of  points  and 
dispatches  them  to  the  equality  function  implemented  in  the  common  point  structure  P.  Generzdly, 
this  makes  bineiry  operations  on  types  dynamically  dispatchable  without  endangering  static  type 
safety  or  requiring  multiple  argument  dispatching. 

A. 2      Based  Set:  Objects  and  Abstraction 

Based  sets  play  em  importcint  role  in  the  implementation  of  the  language  SETL  [SDDS86].  At 
specification  level,  a  based  set  is  pcirametrized  by  the  element  type  cind  provides  a  set  type  and  a 
"translated"  element  type,  both  of  which  are  abstract.  Various  set  operations,  overloaded  for  use 
with  based  or  unbased  sets,  aire  provided. 

spec  basedSet [elem   ::   Eq]   = 
type   set 
type  belem 

in:   elem  *   set  ->  bool 
vith:    set  •  elem  ->  bool 
less:    set  *  elem  ->  bool 

in:   belem  »  set  ->  bool 
vith:    set  *  belem  ->  bool 
less:    set   *  belem  ->  bool 

lookup:   elem  ->  belem 

union:    set   »   set  ->   set 
—  etc. 

A  simple,  inefficient  implementation  of  a  based  set  can  be  given  by  representing  the  set  as  a  bitvector 
and  the  translated  elements  as  indices  into  the  bitvector.  In  addition,  we  need  a  hidden  variable 
representing  the  translation  from  indices  to  actual  elements,  implemented  as  a  sequence^  We  give 
implementations  of  the  different  set  operations. 

struct  basedSet [elem   ::    Eq]    = 
type   set   =   Seq[Bool] 
type  belem  =  Nat 
type  bset   =  Seq[elem] 
vaLT  base:   bset 

in(b:   belem,    s:    set):   bool   =   if  b  >   #  base  then  false  else  s [belem] 
withCs:    set,   b:    belem):    set   =   s [b    :=  true] 
less(s:    set,   b:   belem):    set  =   s [b    :=  false] 


^The  efficiency  could  be  improved  by  using  an  associative  data  stnictuie,  e.  g.  a  hash  table. 
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lookup(e:  elem) :  belem  =  lookup(e,  base) —  only  this  lookup  is  erported 
lookup(e:  elem,  bs :  bset)  :  belem  =      —  this  one  is  hidden 
if  #  s  =  0  then 

0 
else 

1   +  lookup(e,   s[2..])   —  this  is  the  inefficient  psirt 

in(e:  elem,  s:  set):  bool  = 

8[lookup(e)]  hemdle  subscript.error  =>  false 
withCs:  set,  e:  elem)  = 

let  1  =  lookup(e)  in 
if  1  =  0  then 

base    :=  base  ++    [e] 
8  ++    [true] 
else 

8[#  1    :=  true]      —  assuming  that  this  maintains  the 

—  sequence  contiguous  by  inserting 

—  appropriate  false  values 
le8s(s:   set,   e:    elem)   = 

s[lookup(e)    :=  false]   handle  8ubscript_error  =>  s 

—  union  etc.    implemented  bitvise,  base  need  not  be  updated 

Note  that  the  hidden  vairiable  base  would  be  called  a  class  variable  in  object-oriented  terminology. 
Given  this  implementation,  we  Ccin  create  variables  of  type  set;  the  base  is  updated  as  operations 
on  the  variables  are  performed. 

A. 3     A  Package  for  Vectors  and  Matrices:  Multiple  Implementations  and  Hid- 
den Types 

This  example  illustrates  the  use  of  a  structure  implementing  several  related  types.  We  show  a 
specification  requiring  two  types,  vec  cind  mat,  and  operations  involving  these  types. 

spec  VecMat[elem  ::   Num]    = 
vec    : :   Type 
mat    : :   Type 


nesvec :   int  •   int  ->  vec 

newmat :    int  *   int  *   int  *   int  ->  mat 


constructors 


+:  vec  *  vec  ->  vec 

-:  vec  ->  vec 

-:  vec  *   vec  ->  vec 

*:  vec  *  vec  ->  elem 

*:  mat  *  vec  ->  vec 

• :  vec  •  mat  ->  vec 

* :  mat  •  mat  ->  mat 


arithmetic  operations 


[.]:    vec   *   int   ->  elem 

[.] :   mat   *   int   ->  vec 

[,.]:   mat   *   int   ->   vec 

[.,.]:    mat   *   int   •   int   ->   elem 


—   indexing  operations 
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Matrices  and  vectors  may  be  dense  or  sparse.  It  is  useful  to  provide  implementations  which 
efficiently  cover  both  cases: 

struct  denseVecMat [elem]    : :   VecMat [elem]   = 
type  vec  =  Array [elem] 
type  mat  =  Array [Array [elem]] 

—  etc. 

struct  speirseVecMat  [elem]  ::  VecMat  [elem]  = 
type  spso'seVecElem  =  elem  *  int 
type  sp2irseHatElem  =  elem  *  int  •  int 
type  vec  =  Seq[8par8eVecElem] 
type  mat  =  Seq[speLr8eMatElem] 

—  etc. 

We  can  now  define  generic  object  types  for  systems  and  solutions  of  linear  equations.  The  type 
anyLinEq  defines  a  tuple  contaiining  a  vector  and  a  matrix  instantiated  from  the  Scime,  arbitrary 
implementation.  We  can  code  functions  independently  of  the  implementation  of  the  objects  passed 
as  pareimeters;  the  Gaussian  elimination  function  below  works  on  dense  or  spzirse  vectors  and 
matrices. 

type  anyLinEq  =  some  vm   ::   VecMat  with  vn.mat  *  vm.vec 
type  anyLinSol  =   some  vm   ::    VecMat  with  Seq [vm.vec] 

gauss(leq:   emyLinEq) :   anyLinSol  = 
open  leq  as  vm [vec, mat]   in 

—  some  Gauss  elimintation  operations 

—  using  operations  defined  in  VecMat 

—  computing  seqOf SpanningVecs 
hide  vm  seqOf SpsomingVecs 
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